1. Technical Field
This disclosure relates to digital signature and digital certificate methods and systems. More particularly, the present disclosure relates to the use of digital signatures and digital certificates with executable software.
2. Related Art
The advent of digital distribution has created new business models for the delivery of software over the internet. In the “try and buy” a digital distribution model, consumers may sample “try and buy” versions of software before making a purchase decision. Such “try and buy” versions consist of locked down versions of software executables that get unlocked after purchase. In a common scenario, an end-user or potential customer may download a freely available, “try and buy” software application (the installer, henceforth) from the publisher website or general-purpose web portals (e.g. www.download.com, www.yahoo.com, etc., portals, henceforth). Typically, a percentage of the users that download and install the “try and buy” installers purchase the software (or services, or subscriptions associated with it) to obtain a full version of the software product. As such, software manufacturers have an incentive to make “try and buy” software available for download by end-users. Software manufacturers do so by placing such “try and buy” versions on their own websites for end users to download. In addition, software manufacturers may distribute these installers across portals, that are not necessarily controlled by software manufacturers. The motivation behind the “try and buy” business model for the software publishers lies in the fact that they get compensated when the consumer makes a purchase related to the “try and buy” software. In addition, portals arrange business deals with software manufacturers, publishers, or aggregators so that the portals are compensated when “try and buy” installers are downloaded from the portal sites and generate revenue. Typically, portals get a revenue share of the price paid by the consumer.
The “try and buy” installers contain means for end users to purchase the full version of the software application. As part of the purchase transaction, the end-users may be instructed to perform various steps in the online purchase transaction. Such instructions may include, for example, 1) textual descriptions to complete an economic transaction, e.g. send a check to P.O. Box xyz, and receive instructions to obtain the full version of the software application, 2) a URL that contains instructions or means for carrying out online e-commerce transactions (e.g. credit card payments), 3) a purchase mechanism built into the application itself, 4) a purchase mechanism built into a wrapper around the software application, or 5) any combination of these instructions. Because the same software product is normally distributed across multiple distribution networks (e.g. multiple portals), a way of tracking, which distribution network was responsible for a particular purchase is required. One way of determining which distribution network was responsible for a particular purchase is to create traceable versions of the software product. One way of creating traceable versions consists of creating different installers that contain information to identify the distribution network in the purchase instructions. For example, a software product may have a purchase URL embedded containing a value identifying a particular distribution network, for example: http://my.trymedia.com/buy?sku=0123&affiliate=abc
Such a URL can be used for software distribution across a distribution network identified by the parameter, “affiliate=abc”. If the same software product is to be distributed across another distribution network (e.g. “affiliate=xyz”), then another version of the same software product must be created having a purchase URL embedded that identifies the other distribution network, for example: http://my.trymedia.com/buy?sku=0123&affiliate=xyz
Software publishers may create different, traceable versions of a software product by a variety of means that are known to those of ordinary skill in the art. For example, 1) recompiling the software executables containing different ancillary information to identify a distribution channel, 2) including such information in an auxiliary file, resource, or data referenced by the instructions of the purchasing process, or 3) any combination of the above. In most cases, it is advisable to create different traceable versions of the same software product without involving the software manufacturer, so the process can be scaled as efficiently as possible. One possible way to do so is to embed distribution related information in a predefined location in the installer or in a predefined location in the registry of a filesystem when an installer is first executed. One benefit of the embedding distribution related information in the installer is that this method does not require the software manufacturer to create a specific version of the software for each distribution network. Nevertheless, creating and managing different installers for each of a growing number of distribution networks has become a very difficult task.
The introduction of digital signatures in executables provides security benefits for software manufacturers and end-users. For end users, digital signatures of executables provide a tool to ensure that the executable has not been modified in any way since it was signed, typically by the software manufacturer. For software manufacturers, the benefit translates in less chances of having their software modified or altered without permission (e.g. by a computer virus that infects the executable), resulting in less support calls and more user confidence in the software. In the Microsoft™ Windows operating system executables, digital signatures are implemented in the form of certificates. In the header of an executable, a certificate table is provided, which contains information to access various attributes of the digital certificate. Once the software manufacturer has signed an executable file, the contents of the executable cannot be easily changed without rendering the certificate invalid or causing the digital signature of the file to mismatch with the digital certificate of the file. In addition, the growing threats of viruses, spyware, and other malware is making operating systems and Internet browser vendors more likely to issue warnings when executable files are not digitally signed. This will surely result in further adoption and widespread use of digital signatures with executables.
However, as described above, it is inefficient to create different versions of software products for different distribution networks. Further, it is very difficult to modify the contents of executables without destroying the integrity of the digital signature of the executable. As such, it is very difficult for someone other than a software manufacturer to create traceable copies of software products; because modifying the ancillary distribution-related information for a traceable copy would invalidate the digital signature.
Thus, a computer-implemented method and system for embedding ancillary information into the header of a digitally signed executable are needed.